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Abstract 

This paper gives an overview of SC(R)'^ - a 
toolset designed to increase the usabihty of for- 
mal methods for software development. For- 
mal requirements are specified in SC(R)'^ in an 
easy to use and review format, and then used 
in checking requirements for correctness and in 
verifying consistency between annotated code 
and requirements. 

In this paper we discuss motivations behind 
this work, describe several tools which are part 
of SC(R)'^, and illustrate their operation on an 
example of a Cruise Control system. 



1 Introduction 

Researchers have long been advocating us- 
ing mathematically-precise ("formal") specifi- 
cations in software projects [pl|. These spec- 
ifications aid in removing errors early in the 
software lifecycle and can be reused in a vari- 
ety of ways: as a reference point during system 
design and during development of test cases, as 
documentation during maintenance, etc. How- 
ever, there is a strong resistance against adopt- 
ing formal methods in practice, especially out- 
side the domain of safety-critical systems. The 
primary reason for this resistance is the percep- 
tion of software developers regarding the appli- 
cability of formal methods - these methods are 
considered to be hard (require a level of math- 



ematical sophistication beyond that possessed 
by many software developers), expensive, and 
not relevant for "real" software systems Q . Al- 
though case-studies (e.g. 0) have shown ap- 
plicability and effectiveness of formal methods 
for various industrial-size systems, this percep- 
tion still remains. Currently, most research 
in formal methods concentrates on improving 
modeling languages and tool support to be able 
to specify and verify larger and more complex 
problems (e.g. 
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16|). However, to facilitate 
a wide-spread use of formal methods, another, 
complimentary approach is necessary: to im- 
prove usability of the methods and the tools and 
to demonstrate the cost-effectiveness of apply- 
ing them to software systems. We believe that 
the way to make formal methods more usable 
is by 

• amortizing the cost of creating formal doc- 
umentation throughout the software life- 
cycle, i.e. using this documentation for 
checking correctness of programs, generat- 
ing test cases and test environments, etc.; 

• using (or developing) easy to read and re- 
view notations (e.g., state-machines and 
tables); 

• decreasing analysis cost through automa- 
tion; and 

• adopting existing technologies wherever 
possible. 

We are interested in specifying and verifying 
event-driven systems, and chose SCR (Software 



Cost Reduction) to be the requirements nota- 
tion used in our project. 

The SCR requirements notation was devel- 
oped by a research group at the Naval Research 
Laboratory as part of the Software Cost Reduc- 
tion project ||Il|, ^. This notation specifies 
event-driven systems as communicating state 
machines which move between states as the 
environment changes. The functional part of 
the system requirements describes the values of 
the system's output variables as a function of 
the system's input (event) and internal state. 
These requirements can be formally specified 
by providing structured decision tables. For 
each output variable, there is a table which 
specifies how to compute the variable's value 
based on its previous value and input events. 

Representing logical formulae using tables 
is a powerful way to visualize information 
which gained acceptance among many practi- 
tioners. Table structure makes specifications 
easy to write and review and allows for high- 
yield mechanical analysis. Tools were devel- 
oped to check mode tables of SCR for cor- 
rectness with respect to global properties using 
model-checking |Q and theorem-proving | [l9| . 
A group at the Naval Research Lab developed 
an industrial-quality tool called SCR* which al- 
lows specifying and reasoning about complex 
systems using SCR Q- SCR* performs checks 
to ensure that the tables are complete and con- 
sistent. Tool-building is not limited to the 
SCR community. For example, David Par- 
nas and his colleagues are working on meth- 
ods and tools to document programs using ta- 
bles ||2^, ^ |2^, |l|, and a group at Odyssey 
Research Associates are developing Tablewise 
- a tool to reason about decision tables Q. 
However, none of these tools are aimed at us- 
ing tabular requirements once they have been 
created. 

During the past several years, we have been 
developing a number of tools that use SCR 
requirements throughout the various stages 
of software lifecycle, and have recently in- 
tegrated them into a toolset called SC(R)^ 
which stands for the SCR Requirements Reuse. 
SC(R)^ allows users to specify their require- 
ments through a visual interface, conducts sim- 
ple syntactical checks, and invokes various tools 
to perform analysis of software artifacts. We 



have developed tools to check requirements for 
correctness and to verify consistency between 
annotated code and requirements, and will de- 
scribe these activities using the Cruise Control 
system - a case study that we recently under- 
took. 

The rest of this paper is organized as fol- 
lows: Section g describes requirements of the 
Cruise Control system. Sections y and Q out- 
line techniques to analyze the consistency of the 
requirements and the correspondence between 
the code and the requirements, respectively. In 
Section g| we summarize our work and outline 
future research directions. 



2 Requirements of Cruise 
Control System 

A Cruise Control system specified by Jim 
Kirby pq | is responsible for keeping an automo- 
bile traveling at a certain speed. The driver ac- 
celerates to the desired speed and then presses 
a button on the steering wheel to activate the 
cruise control. The cruise control then main- 
tains the car's speed, remaining active until one 
of the following events occurs: (1) the driver 
presses the brake pedal; (2) the driver presses 
the gas pedal; (3) the car's speed becomes un- 
controllable; (4) the engine stops running; (5) 
the driver turns the ignition off; (6) the driver 
turns the cruise control off. If any of the first 
three events listed above occur, the driver can 
re-activate the cruise control system at the pre- 
viously set speed by pressing a 'resume' button. 
Table M gives an overview of the different 
sections of an SC(R)'^ requirements specifica- 
tion. SC(R)'^ uses a simplified SCR method in 
which monitored and controlled variables have 
just boolean values (representing predicates on 
inputs and outputs), and results of intermedi- 
ate computations (so called "terms") are not 
used. Monitored variables in our case study 
indicate the state of the ignition, brake, and 
acceleration, the buttons operating the cruise 
control system, and the speed of the car. Ta- 
ble ^ shows some monitored variables and the 

^The value of THRESHOLD is not specified in ^. 
That document suggests to use a "value chosen ac- 
cording to how wide a speed variation is regarded as 
acceptable." 



Component 


Description 


monitored variables 


quantities that influence the system behaviour 


mode classes 


sets of states (called modes) that partition the monitored 
environment's state space 


controlled variables 


quantities that the system regulates 


assumptions 


assumed properties of the environment 


goals 


properties that are required to hold in the system 



Table 1: Components of a requirements specification in the SC(R)'^ notation. 
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Initial Mode: Off (^Ignition) 
Table 4: Mode transition table for mode class CC of the cruise control system. 



predicates they represent. 

The Cruise Control system has one mode 
class CC, whose modes are described in Ta- 
ble ^. The system is in exactly one mode of 
each modeclass at all times, so we can think 
of modeclasses as finite-state machines. The 
mode transition table of mode class CC is shown 
in Table H. Each row of the table specifies 
an event that activates a transition from the 
mode on the left to the mode on the right. 
The system starts in mode Off if Ignition is 
false, and transitions to mode Inactive when 
Ignition becomes true, i.e., has a value false in 
the current state and a value true in the next, 
indicated by "@T" in the mode transition ta- 
ble. Once in mode Inactive, the system re- 
mains there until Ignition becomes false (in- 
dicated by "@F"), at which point it switches 



to mode Off. The system also transitions from 
Inactive to Cruise if b_Cruise becomes true 
while Running is true (indicated by "t"), and 
Toof ast. Brake, Accel are false (indicated by 
"f"). Values of monitored variables indicated 
by "-" are not relevant to that particular tran- 
sition, e.g., a variable Brake in the transition 
from Off to Inactive. An SCR specification 
defines one mode transition table for each mode 
class of the system. Such tables are entered 
into SC(R)'^ using a mode class editor shown 
in Figure [|. 

The Cruise Control system has a number of 
controlled variables to control the car throttle 
and display messages when the car is due for 
service or when it needs more oil. For exam- 
ple, a variable ThrottleAccel is true when the 
throttle is in the accelerating position and false 
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Figure 1: SC(R)"^ mode class editor. 



otherwise. The condition table for this variable 
is shown in Table a. ThrottleAccel is only 
evaluated in mode Cruise. The first row of 
the table specifies that ThrottleAccel should 
become true when the speed is too slow, and 
false when the system exits the mode Cruise 
(indicated as @F(Inmode)). When the system 
enters Cruise because the user pressed the re- 
sume button, the cruise control needs to main- 
tain the previously set speed. Thus, the current 
speed is immediately evaluated, and if it is too 
slow, ThrottleAccel should become true, as 
indicated in the second row of the table. An 
SCR specification defines one table for each 



controlled variable of the system. The SC(R)'^ 
module for specifying these variables is shown 
in Figure ||. 

SC(R)'^ allows to record assumptions of the 
requirements about the behavior of the envi- 
ronment. Assumptions specify constraints on 
the values of conditions, imposed by laws of 
nature or by other mode classes in the sys- 
tem. In particular, we can assume that the 
engine is running only if the ignition is on 
(Running — 3> Ignition), the car can be go- 
ing "too fast" only if it is running (Toof ast 
— 3> Running), and various boolean condi- 
tions are related by enumeration. The later cat- 
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Figure 2: SC(R)'^ controlled variable editor. 
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Cruise 


@T(speed_slow) 
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@T(Inmode) WHEN [b_Resume & speed.slow] 


@F(speed_slow) 



Initial: False 



Table 5: Event table for the controlled variable ThrottleAccel. 



Variable 


Description 


Ignition 


ignition is on 


Running 


engine is running 


Toofast 


Sp_Vchiclc > MAX_SPEED 


Brake 


brake pedal is being pressed 


Accel 


gas pedal is being pressed 


b_Cruise 


cruise button is being pressed 


b_Resume 


resume button is being pressed 


b_Off 


off button is being pressed 


speed_slow 


Sp_Vehicle < Sp_Desired - 
THRESHOLD^ 



Table 2: Select Cruise Control monitored vari- 
ables. 



egory includes predicates on the vehicle's speed 
(speed_slow / speed_ok / speedJast) and 
buttons controlling the cruise control system 
(b_Off / b_Cruise / b_Resume). 

The last section of requirements specification 
consists of the system goals. These are not con- 



Mode 


Description 


Off 


vehicle's ignition is off 


Inactive 


vehicle's ignition is on, but the 
cruise control is not on 


Cruise 


the cruise control is on and can 
control the vehicle's speed 


Override 


the cruise control is on but cannot 
control the vehicle's speed 



Table 3: Modes of the mode class CC. 



straints on the system behaviour but rather pu- 
tative theorems - global properties that should 
hold in the system under specification, e.g. 
"the light will eventually become green" , or 
"reversing a list twice gives us the original list" . 
The language for specifying these properties in 
SC(R)'^ is an extension of CTL (Computational 
Tree Logic) . CTL is a branching-time temporal 
logic [|6| which allows quantification over some 
or all possible futures. CTL formulae are de- 
fined recursively: all propositional formulae are 



in CTL; if / and g arc in CTL, so are ^/ (nega- 
tion), f Sz g (conjunction), and / | g (disjunc- 
tion). Furthermore, the universal (A) and the 
existential (E) quantifiers are used alongside 
the "next state" (X), "until" (C/), "future" (F) 
and "global" (G) operators. Thus, the formula 

AGif ^ g) 

means that it is invariantly true that / implies 

9- 

In addition to propositional formulae, our 
language allows to express properties involving 
SCR events, e.g. 

[Property 1] If the system is in 
mode Override, then it will react to 
the event @F(Ignition) by immedi- 
ately going to the mode Off. 

The semantics of events @T(a) (@F(a)) is that 
a is true (false) in the current state and false 
(true) in the previous. To ease the phrasing of 
CTL formulas that refer to the occurrence of 
conditioned events, we use unary logic connec- 
tives @T and @F to express the SCR notions 
of becoming true and becoming false. 

Typically, the properties we are interested in 
specifying include invariants, reachability prop- 
erties - these are important to ensure that the 
invariant properties are not true vacuously, and 
"progress" (bounded liveness) properties. For 
example, some of the invariant properties of the 
Cruise Control system is "whenever the system 
is in mode Override of modeclass CC, the sys- 
tem is running and the ignition is on" , formal- 
ized as 

AG(CC = Override —^ (ignition & Running)) 

and "predicates representing the state of the 
Throttle are related by enumeration", formal- 
ized as 

AG(ThrottleOf f [ ThrottleMaintain 
ThrottleAccel | ThrottleDecel) 

"Progress" properties are used to check that 
the system behaves according to our expecta- 
tions. For example, one of the "progress" prop- 
erties of the Cruise Control system is Property 
1 given above, formalized as 

AG{CC = Cruise -^ 
^X(@F(lgnition) ^ CC = Off)) 



Note that in this property we use a logical 
connective @F. 



3 Checking Consistency of 
Requirements 
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Figure 3: Requirements analysis with SC(R)" 



System goals allow semantical checks on re- 
quirements, i.e. checks that these goals hold in 
the specification of the system. We chose to 
use model- checking [pj to perform these checks. 
A symbolic model-checker SMV developed by 
McMillan ll^, uses state exploration to check 
if temporal properties hold in a finite-state 
model. However, we first needed to translate 
the behavioral specifications of SCR into a for- 
mat accepted by SMV, which is done using a 
tool gensmv. The requirements analysis pro- 
cess is depicted in Figure |3|, where tools and 
artifacts are represented by ellipses and boxes, 
respectively. In this section, we briefiy de- 
scribe gensmv, outline counter-example facili- 
ties of SMV and SC(R)'^, and present results of 
verification of the Cruise Control system. 



3.1 Translating SCR Specifica- 
tions 

gensmv Q was developed at the University 
of Waterloo to reason about mode transi- 
tion tables. Before translating SCR specifica- 
tions, gensmv details the mode transition tables 
with information derived from environmental 
assumptions. For example, an assumption 
Running — 3> Ignition adds information to 
the second transition from mode Inactive to 
mode Cruise (third row of Tabled): if Running 
is true, then Ignition should already be true. 
Detailed SCR tables are translated into the 
SMV input language. In order to translate added 
logic connectives @T and @F to regular CTL, 
accepted by SMV, gensmv needs to store pre- 
vious values of variables which can occur in 
events. This is facilitated by introducing addi- 
tional variables in the SMV model. For example, 
in order to reason about a property involving 
@F(lgnition), we need an additional variable 
PIgnition, which is assigned the current value 
of Ignition before the next value of this vari- 
able is computed. Thus, Property 1 is trans- 
lated into CTL as 

AG{CC = Cruise -^ AX((PIgnition & 
^ Ignition) ^ CC = Off)) 

We extended gensmv to translate condition ta- 
bles of controlled variables into the SMV mod- 
eling language Q. This way, we are able to 
reason about the entire SC(R)'^ specification. 

3.2 Counter-examples 

During verification of CTL properties, SMV ex- 
plores all possible behaviors of the model and 
either declares that the property holds or gives 
a counter-example. Since we wanted to make 
calls to SMV completely transparent to the user, 
and because of the introduction of extra vari- 
ables into the SMV model, we found it neces- 
sary to automatically capture SMV's counter- 
examples and translate them into the SCR for- 
mat. This translation allows the user to easily 
determine where errors occur, without having 
to understand the intricacies of translation be- 
tween the SCR and the SMV models. 
For example, if we try to check the property 
"pressing the Cruise button at any point when 
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Figure 4: A counter-example generated during 
the requirements analysis. 



the system is running will turn the cruise con- 
trol system on" , formalized as 

^G((Running & @T(b_Cruise)) 
-^ AF{CC = Cruise)) 

SC(R)'^ reports a scenario that would violate 
this property, shown in Figure ^. Thus, the 
system does not react to changes in b_Cruise 
if the car is running too fast to be controlled 
by the automatic system. 

3.3 Checking the Cruise Control 
System 

We were successfully able to model and ver- 
ify the automobile cruise control system using 
the SC(R)'^ toolset. The verification was per- 
formed on a moderately loaded SPARCstation- 
20 (2 75 MHz processors) with 256 megabytes 
of RAM using SMV version 2.4. The complete 
Cruise Control specification consists of 22 mon- 
itored and 13 controlled variables, translated 
into 47 SMV variables. Given that the size of 
the model grows exponentially to the number of 
variables in the system, we were not surprised 
that the initial runs of SMV did not complete 
after two days. However, we explored various 
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Table 6: Verification of tlie Cruise Control specification: experimental results. 



ways to reduce the time and memory require- 
ments necessary to verify the system. The fol- 
lowing is the summary of our findings. 

• The most effective technique is "slicing", i.e., 
removing variables that are not used in proper- 
ties under verification. Currently, if a variable 
does not appear in any of the properties and 
no other variables depend on it, SMV still in- 
cludes it into the models it builds. However, 
it is safe to remove such variables from con- 
sideration, thus greatly reducing sizes of the 
models. In SCR, there is a hierarchy of depen- 
dencies between requirements' variables, which 
is very easy to compute and take advantage of, 
although at the expense of producing separate 
SMV models. In SC(R)'^, the later process can 
only be done by hand so far, although we are 
developing an automatic model generation. 

• Another technique is turning the variable re- 
ordering on. SMV uses binary decision diagrams 
(BDDs) to quickly manipulate logical expres- 
sions. Unfortunately, the size of the BDDs is 
extremely sensitive to the order of the vari- 
ables used to build them [g^. SMV has an op- 
tiong — reorder that allows it to heuristically 
compute and use a "better" variable reorder- 
ing which is typically very effective. However, 
even with reordering turned on, SMV took a 
long time to verify the Cruise Control speci- 
fication (26487.25 seconds of user time). To 
overcome this problem, we split the model into 



two: mode classes and controlled variables re- 
lated to the throttle, and mode classes and all 
other controlled variables. Results of our ex- 
periments appear in Table ^. In this table, we 
list the user and the system time in seconds, 
and the total number of BDD nodes used dur- 
ing the verification, as reported by SMV. The 
last column of the table is the number of vari- 
ables in the SMV model. We were unable to 
measure the running time in terms of real time, 
since SMV does not keep this information. 
• A more controversial technique is building the 
state space incrementally, removing unreach- 
able parts of the model (SMV options — f and 

inc). This technique reduces the size of 

BDDs at the expense of the longer running 
time. Combining this option with — reorder 
typically yields a smaller number of BDD nodes 
than either of the options alone, but the veri- 
fication time is slightly worse than by running 
SMV with with — reorder alone (see Table @). 
We feel that both options should be turned 
on on a fast machine with a limited amount 
of memory, whereas just — reorder should be 
turned on on a slower machine. 

The verification effort yielded a number of 
errors, most of which could be traced back to 
the original specification [|l5| . We found no er- 
rors in the mode transition table because this 
table has been analyzed earlier by Atlee and 
her colleagues mH. However, we did find er- 



^Version 2.5 of SMV uses variable reordering by 
default. 



•^However, our study showed that a number of con- 



Throttle Setting 


Mode 


Condition 


Cruise 


speed_slow 


speed_ok & 
^Accel 


speed_f ast & 
^Accel 


Accel & 
^ speed. 


slow 


Throttle 


Accel 


Maintain 


Decel 


Off 



Table 7: Condition tabic for variable Throttle. 



rors in controlled variable tables of the origi- 
nal specification. For example, the cruise con- 
trol system includes a controlled variable OilDn 
which represents lighting up an indicator when 
the vehicle is due for an oil change, i.e., it 
has traveled a certain distance since its pre- 
vious oil change. In Kirby's specification, this 
controlled variable is evaluated when we enter 
any mode other than Off (OTdnmode) when 
Omiles_low). Thus, the vehicle could be trav- 
eling with the cruise control system turned off, 
not changing its modes and never setting OilOn 
to true. We modified the table for OilOn to set 
the variable to true when Omiles_low becomes 
true, regardless of the mode. 

Another problem was found in the table for 
evaluating the throttle. In the notation used by 
Kirby, Throttle was an enumerated variable 
whose values are evaluated in mode Cruise as 
specified in Table 0. We found that condition 
'^Accel is redundant - the system exits mode 
Cruise as soon as Accel becomes true. We also 
suspected that the throttle might never become 
Off. To check that, we modeled the variable 
Throttle in SMV and ran it against the prop- 
erty 

-- Throttle = Off -^ AG{^ Throttle = Off) 

which was verified, confirming our suspicion. 
Finally, the correctness of the specification is 
conditional upon the time when the predicate 
on the vehicle's speed is evaluated. It works 
correctly only when speed_ok, speed_slow and 
speedJast get evaluated before the system 
transitions into mode Cruise. 



ditions used in Atlce's specification were not neces- 
sary, e.g., specifying that transitions from Override to 
Cruise occur only when Running and Ignition are true. 
These conditions are imphed by other transitions in the 
mode table and did not need to be specified explicitly. 



4 Checking Correctness of 
Code 

At some point in the future it will be possible 
to generate code from the black-box require- 
ments specified in SCR. However, this code 
will likely require some hand-tuning, e.g., be- 
cause it is too slow, or might even have to be 
rewritten from scratch. Mathematically pre- 
cise software requirements, like SCR, can be 
used to reason about correctness of implemen- 
tations. SC(R)'^ incorporates a tool called cord 
1^ that takes specially annotated source code 
and an SCR specification and checks for the 
correspondence between them, cord uses data- 
flow analysis instead of exhaustive state enu- 
meration to enable effective verification in low- 
degree polynomial time. However, the analysis 
can sometimes be imprecise, i.e. "there may be 
a problem on this line of the code" . In this sec- 
tion, we describe how to (correctly) annotate 
the code, outline the algorithms used in cord 
to check consistency between requirements and 
annotated code, and present results of verify- 
ing the implementation of the Cruise Control 
System. 

4.1 Annotations 

Code is annotated with special statements 
which describe changes in the system state. 
These changes involve local (rather than invari- 
ant) information and therefore are relatively 
easy to specify. The annotations, described in 
detail in Q, are of three types. Initial anno- 
tations indicate the starting states of the pro- 
gram. They unconditionally assign values to 
variables and correspond to initialization infor- 
mation specified in the requirements. Update 
annotations assign values to controlled, mon- 
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Figure 5: Code analysis with SC(R)" 



itored or mode class variablesn. These anno- 
tations identify points at which the program 
changes its state. Assert annotations assert 
that variables have particular values in the cur- 
rent system state. This makes our analysis 
more precise and serves as documentation of 
what the developer assumes about the system 
at a given point in the program. 

Consider the following annotated code frag- 
ment, taken from the implementation of the 
Cruise Control system:^ 

if (Ivlgnition) { 

®@ Assert "Ignition; 

vignition = true; 

@@ Update Ignition; 

vCC = minactive; 

m Update CC=Inactive; 
} 
else ■[ 

@(§ Assert Ignition; 

vignition = false; 

@@ Update "Ignition; 

vCC = mOff; 

m Update CC=Dff; 
} 



* Monitored and controlled variables have boolean 
values; mode class variables have values which form 
enumerated types whose constant values are modes of 
the mode classes. 

^Lines that start with @@ indicate annotations. 



In this fragment, code variables vignition 
and vCC correspond to requirements variables 
Ignition and CC. In the Then branch of the 
If statement we assert that Ignition is false, 
register that Ignition becomes true, marked 
by an Update annotation, and then change the 
mode of the system to Inactive. This is also 
marked by an Update annotation. The Else 
branch is similar. 

As stated above, cord uses annotations and 
control-flow information of the code to check 
it for correctness. That is, "the analysis is 
as good as the annotations" . Although anno- 
tations are easy to insert, we found ourselves 
frequently making mistakes, and also noticed 
that code maintenance greatly reduces the cor- 
respondence between the code and the annota- 
tions. Thus, the SC(R)'^ toolset includes a tool 
called sac g designed to check that the code 
is annotated correctly. To use the tool, the 
programmer creates a list of correspondences 
between variables in the requirements and the 
code. For example, the following is the speci- 
fication of correspondences for the above code 
fragment: 

correspondences : 
■(Ignition} -> {vignition}; 
■CCC} -> -[vCC}; 

These correspondences can be one-to-one 
(one requirements variable corresponds to one 



code variable), one-to-many (one requirements 
variable corresponds to several code variables), 
and many-to-one. sac ensures that an assign- 
ment to (a check of) a code variable is always 
followed by an Update (an Assert) of an ap- 
propriate requirements variable. The entire 
process of code verification with SC(R)'^ is de- 
picted in Figure 0. Here, tools (sac and cord) 
and artifacts are represented by ellipses and 
boxes, respectively. 

4.2 Analysis 

Analysis done by cord is described in detail 
elsewhere M. In this section, we give a quick 
summary of this process. 

cord checks that transitions implemented in 
the code are exactly the same as those spec- 
ified in the requirements. These checks corre- 
spond to three types of properties: (1) the code 
and the specification start out in the same ini- 
tial state; (2) the code implements all speci- 
fied transitions; and (3) the code implements 
only specified transitions. Properties of types 
(2) and (3) are called ALT ("all legal transi- 
tions") and OLT ("only legal transitions"), re- 
spectively. For example, cord checks an ALT 
property that a transition from mode Cruise 
to mode Off on event OF (Ignition) exists in 
the code. This transition refers to the fourth 
row of Table 0. One of the OLT properties is 
"the only transitions into mode Off are from 
mode Inactive on event @F( Ignition), or 
from mode Cruise on event OFdgnition), or 
from mode Override on event OFdgnition)". 

Verification is done via static analysis of the 
annotated code. A technique similar to con- 
stant propagation is used to create a finite-state 
abstraction of the annotations and control-flow 
program statements of the program. We use 
an aggressive state-folding strategy aimed at 
minimizing the number of states. This number 
is bound above by the number of annotations 
and control-flow structures in the code and is 
almost not affected by the number of variables 
in the specification. After the model has been 
created, we check it for consistency with the 
specification. Typically, the properties involve 
fairly short (2-3 states) fragments of the paths 
through the code, thus enabling very efficient 
checking. In addition, cord can verify invari- 



ant and reachability properties, find unreach- 
able states, and check that environmental as- 
sumptions are not violated in the code. 

Fast and highly scalable processing comes 
at a price of inexact verification. Abstraction 
used in cord leads to computing more behav- 
iors than can be present in the code. Thus, 
OLT properties and invariants are checked pes- 
simistically^ i.e., some violations that are not 
present in the code can be reported. ALT and 
reachability properties are checked optimisti- 
cally, i.e., some violations in the code can be 
overlooked. We believe that cord should be 
used as a debugging rather than a verification 
tool and found it to be extremely effective in 



discovering errors (see Section 4.3) 
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Figure 6: Summary of errors. 



We had to resort to annotating code be- 
cause our analysis techniques could only handle 
simple operations on booleans and enumerated 
types. A next generation of cord is currently 
being developed. For finite types, this version 
of the tool will be able to handle more interest- 
ing operations, like addition and comparison. 
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Figure 7: ALT errors. 



It will also be able to approximate infinite types 
and perform operations on them using abstract 
interpretation [g| . This will allow us to analyze 
code directly rather than using annotations. 

4.3 Checking the Cruise Control 
System 

We have implemented the Cruise Control sys- 
tem in C with an Xlib interface. The implemen- 
tation was not originally annotated and con- 
sisted of 675 lines of code, out of which roughly 
380 lines were used to implement the GUI of the 
system. The code was then annotated by an- 
other member of the group in about 40 minutes; 
the annotation effort was trivial and resulted in 
37 Update, 25 Assert and 1 Initial annotation. 
After fixing annotation errors reported by 
sac, we ran cord on the code of the Cruise 
Control system. The analysis took 7.62 sec- 
onds (3.45 user, 0.74 system, as reported by 
tshell's time command) on a moderately loaded 
SPARCstation-4 (85 MHz processor) with 64 
megabytes of RAM, and resulted in reporting 
14 ALT and 5 OLT violations (see Figure |). 
The ALT and the OLT violations are shown in 
Figures and g, respectively. 



One OLT and one ALT violation were caused 
by an incorrect annotation overlooked by sac. 
sac does not consider values of variables when 
checking code for correct annotations, and did 
not report a violation when we annotated an 
assignment with Accel instead of ^^Accel. An- 
other pair of OLT and ALT violations came 
from an incorrect transition in the code (line 
388) - to mode Override instead of Cruise. 
In addition, cord computed that the system 
can be in all possible modes before this line, 
whereas only Cruise is possible. This problem 
arises because of the imprecise analysis used 
in cord and can be fixed by adding an ex- 
tra Assert annotation. A yet another pair of 
OLT and ALT violations came from a transi- 
tion from Override to Cruise. The code did 
not check that this transition is only enabled 
when Toof ast. Brake and Accel are false. Out 
of the remaining two OLT violations, one was a 
false negative and the second was an incorrect 
triggering event for the variable ThrottleOff . 
All other ALT properties came from transitions 
that were not implemented in the code. 

5 Conclusion 

In this paper we presented SC(R)"^ ~ an inte- 
grated toolset for specification and reasoning 
about tabular requirements. Through a uni- 
fied interface, SC(R)'^ allows to check software 
requirements for correctness and analyze con- 
sistency between annotated code and require- 
ments. We are currently working on develop- 
ing support for automatic code generation and 
are looking into ways of using SCR for gener- 
ation of black-box test cases. We believe that 
SC(R)'^ is an important step towards increas- 
ing usability of formal methods: it attempts to 
replace free-form reasoning in logic by easy to 
write and review structured tables and amor- 
tizes the cost of creation of formal requirements 
through multiple automated analysis activities. 
We envision the following methodology for us- 
ing SC(R)3: 

1. A (human) requirements designer provides 
an SCR tabular specification of the sys- 
tem's required behavior and a set of global 
properties that should be satisfied by the 
system. 
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Figure 8: OLT errors. 



2. SC(R)^ automatically translates the SCR 
specification into the input to a model- 
checker, verifies properties and translates 
counter-examples into the SCR notation. 

3. Once the specification is considered cor- 
rect, SC(R)^ generates an implementation 
of the mode logic and stubs for interface 
code, which are filled in by a human de- 
veloper. 

4. Using the specification, SC(R)'^ generates 
test cases. Although the mode logic is cor- 
rect by construction, interface is likely to 
need testing. 

5. The resulting implementation is analyzed 
for performance and optionally manually 
fine-tuned. 

6. If manual fine-tuning was used, the code is 
automatically checked for consistency with 
its specifications. 

7. Once the problems pointed out by the 
analysis are fixed, the code is tested us- 
ing (a subset of) test cases generated in 
step (4) above. 

In Figure ^, analysis activities performed 
within SC(R)'^ and software artifacts are shown 



inside ellipses and boxes, respectively. For ex- 
ample, the code generation activity takes SCR 
requirements as an input and generates an im- 
plementation in C. A dashed line signifies that 
the generated code and the code that is ana- 
lyzed for correctness, represent the same arti- 
fact. 

In SC(R)'^, requirements analysis is done via 
mo del- checking. Although model-checking is 
an effective verification technique which can be 
used without any user input, it has a num- 
ber of limitations. Checking can often be pro- 
hibitively expensive and cannot usually be ap- 
plied to infinite-state systems. Thus, we are 
limited to verifying just control (as opposed 
to data or timing) aspects of the specification. 
In order to use model-checking effectively, we 
had to reduce the expressive power of our in- 
put logic, which may not be feasible for many 
applications. We recognize that more sophis- 
ticated verification might be necessary and are 
planning to experiment with using a theorem- 
prover, e.g. PVS pSl, to check complex type- 
checking and timing properties of systems. 

Code verification in SC(R)'^ is done via a 
static- analysis tool cord. Although effective 
in finding errors in our case studies, cord is 
still a prototype tool in need of major improve- 
ments. We are currently redesigning it to pro- 
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Figure 9: Pictorial description of activities that can be performed with SC(R)^ 



cess a more expressive annotation language and 
reason about infinite-domain variables. This 
would make cord able to verify implementa- 
tions of unrestricted SCR specifications. 
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